Computers, configured as virtual machines, are well known today. In this configuration, a hypervisor program logically divides physical resources (including CPU, memory, storage and I/O devices) of a real computer into separate virtual machines. For example, the hypervisor allocates to each virtual machine a time share of one or more real processors and a range of virtual private memory mapped to real RAM. When a virtual machine addresses its own virtual private memory, the hypervisor translates the virtual private memory address into a real address of real memory. The hypervisor also allocates virtual private memory to itself to store the hypervisor program, including its control structures, and data used by the hypervisor program. In a known IBM z/VM operating system, the hypervisor program is called a Control Program (“CP”), and each virtual machine may also be called a “user portion” or “guest”.
It was also known for a logical partitioning program to logically divide the physical resources of a real computer (including CPU, memory, storage and I/O devices) into logical partitions (“LPARs”), and then for a hypervisor program to execute in each LPAR and divide the resources of each LPAR into virtual machines. In a known IBM zSeries computer, a known IBM Processor Resource/Resource Manager (“PR/SM”) program divides or partitions a real computer into LPARs. Typically, an administrator assists in defining each LPAR by specifying to the logical partitioning program the amount of CPU, memory and storage for each LPAR. The logical partitioning program can allocate to each LPAR specific real computer resources or a logical share of the total computer resources. The virtual machines in each LPAR operate in the same manner as if they were formed directly from the real computer without any logical partitioning.
A previously known IBM z/VM version 5.1 virtual machine operating system includes a known hypervisor program which forms virtual machines from LPARs or from an undivided real computer. The details of the existing z/VM 5.1 operating system are disclosed in IBM publications “z/VM Version 5 Release 1.0 General Information” (Document Number: GC24-6095-00) with “z/VM Version 5 Release 1 Updated Edition” (Document number GC24-6095-01) which are available from International Business Machines Corp. at PO Box 29570, IBM Publications, Raleigh, N.C. 27626-0570 or on the WWW at the IBM home page with suffix “/shop/publications/order”. These publications are hereby incorporated by reference as part of the present disclosure.
A guest operating system executes in each virtual machine (using the virtual machine's share of CPU, memory, etc.). One or more applications and middleware programs (such as a file manager) execute on each guest operating system. Even though each application, middleware program and guest operating system are executing in a virtual machine, they operate as if they are executing in their own private, real computer. The guest operating system in each virtual machine can be the Linux (™ of Linus Torvalds) operating system, IBM CMS operating system or other operating system. The application and middleware that execute on each guest operating system on each virtual machine can be an IBM DB2 data base management application, IBM Websphere application, or various other programs.
The guest operating system, middleware, application(s) and data for each virtual machine are stored in a working memory portion of the virtual private memory allocated to the virtual machine. Each virtual machine also includes a cache memory portion of the virtual private memory allocated to the virtual machine. The cache memory contains data accessed from (disk) storage and associated metadata. The metadata comprises a directory and sub directory path to the data file, identities of records within the file currently being written or read, size of the file, size of records in the file, type (ASCII, EBCDIC or BINARY) of data in the file, where the file is stored on disk, etc. Most guest operating systems include some algorithm for determining which pages of data should will remain in the cache memory when the cache is full and which pages of data should remain in the working memory when the working memory is full. For example, most guest operating systems use a least recently used algorithm to outpage the least recently used data from the cache memory to external storage when there is insufficient room in the cache memory for new data needed by the virtual machine, and use a similar algorithm to outpage the least recently used data from the working memory to external storage when there is insufficient room in the working memory for new data needed by the virtual machine.
A virtual machine may also include a swap memory portion of the virtual private memory allocated to the virtual machine from RAM. A swap memory of a virtual machine is used as a memory location to receive and store data paged out from cache memory and working memory instead of paging out the data to disk storage. In a typical scenario, when there is insufficient cache memory or working memory to store data (information or programs) needed by the virtual machine, the guest operating system in the virtual machine identifies the least recently used memory data (as four Kilobyte pages) in cache memory or working memory of the virtual machine. Then, the guest operating system can copy the least recently used memory pages to swap memory or disk storage in the virtual machine. The guest operating system determines whether to page-out to swap memory or (disk) storage based an administrator-defined configuration of the virtual machine. The administrator can configure the virtual machine to page-out to one or other or to page-out to swap memory until full and then page-out to disk. Paging out frees up cache memory and working memory to enable the guest operating system to inpage other, more needed pages of data from swap memory or storage to cache memory or working memory.
The Linux operating system (and other operating systems), as a guest operating system, virtualizes the virtual private memory that the hypervisor allocates to it. In its own virtualization process, the Linux operating system over-commits the virtual private memory that the hypervisor has allocated to it. For example, assume that the hypervisor allocated three Gigabytes of virtual private memory to the virtual machine having the Linux (or other) guest operating system. In response, the Linux guest operating system may itself virtually allocate six Gigabytes to processes executing on the Linux operating system. This is realistic because the processes typically use, on average, much less memory than allocated to them. Nevertheless, the Linux operating system (and Microsoft Windows operating system) tends to keep stale data in its working memory and cache memory, because there is some chance that it will be needed in the future and this will reduce outpaging and inpaging. Because of this, typically, the Linux operating system either fails to utilize swap memory or substantially under utilizes its swap memory during normal operation, even when the Linux operating system is configured to use swap memory for page outs.
The hypervisor tracks how much memory (called the “working set”) that each virtual machine has used during a prior interval. The hypervisor uses the combined size of the “working sets” of all the virtual machines to determine how much memory is available for itself and other virtual machines that it may subsequently create. The hypervisor over-commits, to itself and the other virtual machines that it may subsequently create, the available virtual private memory because the hypervisor and all virtual machines typically do not use all of their respective memory allocations.
Occasionally, the hypervisor needs additional memory for its own operation, to form another virtual machine, or to allocate to an existing, critical virtual machine which is short of memory. In any such case, the hypervisor (such as found in IBM z/VM 5.1 operating system) can make requests to the virtual machines with excess virtual private memory to voluntarily relinquish some of their existing allocation of virtual private memory. Typically, in response to the request, the virtual machines will relinquish some of their total virtual private memory allocation, and then rebalance their amounts of working memory and cache memory based on their remaining allocation of virtual private memory. Some guest operating systems will relinquish virtual private memory solely from their cache memory if available. The swap memory allocation, if any exists, is unaffected. However, this may leave some or all of the virtual machines with insufficient amounts of virtual private memory to effectively perform their work items.
An object of the present invention is to better manage allocation of memory.
Another object of the present invention is to better manage allocation of memory to virtual machines.